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Communicating between )ayAlmarode 
sessions 


I n multiuser environments, users often want to com¬ 
municate with each other. In some cases, they want to 
broadcast their message to all interested parties; in 
other cases, they only want to carry on a dialog with one 
other user. In a system that supports transactions, an 
application sometimes wants to be notified when changes 
to parti cu I ar obj ects have been committed. A cl i ent/ server 
system al ready has the i nfrastructure to provi de these ser- 
vi ces The cl i ent and server al ready have predefi ned com- 
munication protocols, and the server has knowledge of all 
theclients currently logged in.Thiscolumn discusses two 
kindsofclient-to-client communications that can be sup¬ 
ported by mu I ti user Smal I tal k and shows how to use them 
to implement concurrent processing algorithms 

In a system that supports transactions, application 
sessions are committing changes to objects all the time. 
Manytimesan application needs to know when another 
concurrent session has committed a change to specific 
objects of interest. For example, a stock broker applica¬ 
tion may want to trigger some activity when the price of 
a particular stock has changed. Or, an inventory manage 
ment application may need to initiate item purchases 
when the inventory dips below a specified threshold. A 
reservation system may want to be notified when a new 
reservable unit becomes available. In these cases, the 
application does not care who made the change; it just 
wants to be notified that a change occurred and which 
obj ects were mod i fi ed. 

In GemStone Smalltalk, classSystem provides protocol 
to receive notification when particular objects are mod¬ 
ified. Each session that is logged in maintains its own'noti¬ 
fy set'. Asession can register objects of interest by placing 
them in its notify set. Thisset only exists for thelife of the 
session; that is, it is not a persistent object, but it is main¬ 
tained across transaction boundaries. An application can 
add a single object to its notify set by executing System 
addToNotifySet: anObject or can add a collection of objects 
by sending addAIIToNotifySet:. There is also protocol to 
access and remove objects from the notify set. 

Once objects have been added to its notify set, there 
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are two ways in which the session can receive notifica¬ 
tion. Oneway is to poll for the objects that have changed; 
the other isto install an exception handler. If the applica¬ 
tion installsan exception handler, it must first enablethe 
ability to receive this error (it is not really an error, but the 
underlying implementation uses the error mechanism to 
interrupt execution). This error is enabled by sending 
System enableSignaledObjectsError. Whether polling or 
handling an exception, to find out which objects have 
been modified, the application sends System signaled- 
Objects. This message returns a set of objects that have 
had changes committed to them and clears the signaled 
objects set for the next use. 

The following section of code illustrates how to install 
an exception handler and get the changed objects: 

"first enable the ability to be notified when 
changed objects are committed " 

System enableSignaledObjectsError. 

" now install an exception handler to catch the notification" 

Exception 

category: GemStoneError 

number: (ErrorSymbols at: frtErrSignalCommit) 

do: [ :ex :cat mum :args | | changedObjects | 

" get the objects that have had changes to them 
committed " 

changedObjects :=System signaledObjects. 

]. 

When adding objects to the notify set, an application 
must consi der what part of an object wi 11 actual ly be writ¬ 
ten, so that the session will be notified when a change to 
that object is committed. For example, an RcCounter 
object (described in an earlier column) isactually imple¬ 
mented as a composite object, composed of multiple 
subobjects that each encapsulates a numerical value. It 
is the sum of all values in the subcomponents that ac¬ 
tually make up the RcCounter's value. When an RcCounter 
is incremented or decremented, it is one of the subcom¬ 
ponents that isactually written. Consequently, to receive 
notification when a change to an RcCounter is committed, 
a session must place the root object and all of its sub¬ 
components in the notify set. 

Another kind of useful cl ient-to-client communication 
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is when two sessions want to talk to one another directly 
and immediately. In GemStone Smalltalk, this is possible 
by sendinga signal to another session currently logged in. 
Asignal consistsofaSmalllnteger, whosemeaningisagreed 
on by the participants in the dialog, and a sequence of 
bytes (a maximum of 1,023). As with the changed object 
notification mechanism just described, signaling is im¬ 
plemented using the underlying error mechanism. Con¬ 
sequently, a sessi on must enablethe recepti on of thesesig- 
nals by sending System enableSignaledGemStoneSession- 
Error. A session can receive signals from multiplesenders, 
and the signals are queued in the order received. 

For a session to send a signal to another session, it must 
i denti fy the other sessi on by its un i que sessi on i dentifi er, a 
Smalllnteger.Thereareacoupleofwaysthata user can find 
out about other sessionscurrently logged i nto the system. 
To get the session IDs of all userscurrently logged in, you 
can send the message System currentSessions, which 
returns an array of Smalll ntegers. For each session ID, you 
can send System descriptionOfSession: sessionld to get back 
an array of more detailed informati on. Amongthepiecesof 
information returned by this message is the name of the 
host machine on which that user is logged in, and the 
UserProfile object for that user. Getting information about 
other users i s a pri vi I eged operati on, so you must have 'ses¬ 
si on access' pri vi lege to send these messages 

Once you have the identifier of the session to which 
you would like to send a signal, you can send System send- 
Signal: aSignalNumber to: aSessionld withMessage: aString. 
The receiver of the signal executes System signalFromGem- 
StoneSession to receive an array of signal informati on. The 
array is empty if no signal has been sent. If a signal has 
been sent, the array consists of three elements: the ses¬ 
sion id of the sender, the signal number, and the bytes 

Because signaling uses the underlying error mecha¬ 
nism, a receiver can install an exception handler to be 
triggered when a signal is sent to it, or the receiver can 
poll for signals. 

Sgnals are a simple mechanism that can be used to 
build complex behaviors that involve more than onecon- 
cu rrent sessi on. One use of si gnal s i s to coordi nate sessi ons 
for implementing concurrent algorithms Implementing 
concu mental gorithmswith individual sessionsmeansthat 
you are allocating tasks among multiple processes, each 
with i tsown ded i cated Smal Ital k i nterpreter and vi ew of the 
object repository. Some care must be taken to make sure 
that each session's transaction point of view treasonably 
uptodatewiththeothersUsuallythismeansthatasession 
begi ns a new transacti on as the fi rst step i n performi ng i ts 
part of theconcu mental gorithm. 

The remainder of this column describes a simple pair 
of classes that can be used for implementing concurrent 
processing. The implementation consists of one class, 
called WorkerBee, whose responsibility is to receive com¬ 
mands to do work, and another class, called QueenBee, 
which sends commands to multiple WorkerBee objects 
and accumulates the results of their work. A QueenBee 
uses signals to send commands to each WorkerBee and 


uses changed object notification to learn when each 
WorkerBee has committed its work. 

The implementation of WorkerBee is fairly simple. Its 
main task is to execute a service loop, waiting for instruc¬ 
tions from any QueenBee. Class WorkerBee defines a single 
instance variable, called amountToSleep that holds the 
number of seconds to delay each time through its service 
loop. This allows the responsiveness of each WorkerBee to 
be tuned. Note that the WorkerBee's OS process and 
resources used can be further control led using configura¬ 
tion parameters as described in an earlier column on tun¬ 
ing. Each time, through its service loop, aWorkerBee checks 
if a signal was received. If so, it initiates some work based 
on the signal number. Because the meaning of signal 
numbers must be agreed upon by the sender and receiver, 
I use a pool dictionary shared by WorkerBee and QueenBee 
to provide symbolic names for different signal numbers. 

The pool dictionary has entries with the following 


meanings: 


fhandshake 

initiate an agreement to work for a 
QueenBee 

#freeWorker 

end the agreement to work for a 
QueenBee 

#execu teString 

execute the given string fora QueenBee 

#commit 

commit the current transaction 

#abort 

abort the current transaction 

terminate 

terminate the service loop of the 
WorkerBee 


AWorkerBee must synchronize with a QueenBee before it 
does any work. In this simple example, a WorkerBee and a 
QueenBee perform a handshake in the following way: A 
QueenBee sends a signal initiating the handshake. In¬ 
cluded in this initial signal is the QueenBee's name. This 
must be a name that the WorkerBee can resolve to get the 
QueenBee instance that sent the signal. If the WorkerBee is 
not already servicing another Queen Bee, it returns a si gnal 
indicating its availability; otherwise it indicates it is busy. 
At this point, the WorkerBee is dedicated to a single 
QueenBee, waiting for commands. The i mplementation of 
the WorkerBee's serviceLoop is as follows (simple portions 
of this method have been omitted for brevity): 

method: WorkerBee 
serviceLoop 

"Start up a loop, waiting for instructions." 

| continue queen queenSessid 
j continue :=true. 

" worker bee loop " 

[ continue ] whileTrue: [ | signalArray | 

signalArray :=System signal Fro mGemStoneSessi on. 

" if no signal was sent, sleep for awhile" 
signalArray isEmpty 

ifTrue: [ System sleep: self amountToSleep ] 
ifFalse: [ 

| signalNumber signalSender signalBytes | 
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signalSender :=signalArray at: 1. 
signalNumber :=signalArray at: 2. 
signalBytes :=signalArray at: 3. 

" command to execute the given string " 
signalNumber = executestring 
ifTrue: [ 

" only accept commands from one queen" 
(queen notNil and: [ signalSender = 
queenSessid ]) 

ifTrue: [ queen addToHive: signalBytes 
_execute ] 

]■ 

" receive a request to work for a queen" 
signalNumber = handshake 
ifTrue: [ 

queenSessid isNil 
ifTrue: [ 

queenSessid :=signalSender. 

" resolve the QueenBee's name to an 
instance" 

queen :=System myUserProfile 

objectNamed: signalBytes. 

System sendSignal: handshake 
to: signalSender 
withMessage: 'Available' 

] 

ifFalse: [" signal that the WorkerBee is 
unavailable" 

System sendSignal: handshake 
to: signalSender 
withMessage: 'Unavailable' 

] 

]■ 

continue :=signalNumber ~=terminate. 

] 

]■ 

The implementation of theQueenBee is also fairly simple. 
Class QueenBee defines three instance variables: its name, 
an array containing the session ID of each of its worker 
bees, and a bag in which each WorkerBee can place the 
result of its work. This last instance variable, cutely 
named hive, will be concurrently updated by multiple 
WorkerBees. To avoid concurrency conflicts, this variable 
contains an instance of RcBag. You may recall from an 
earlier column, an RcBag has concurrency semantics such 
that concurrent adders to the bag wi 11 not confl ict. 

In addition, theQueenBee wantsto benotified when each 
WorkerBee has committed theresult of itsworktotheRcBag. 
Toaccommodatethis,theQueenBee placestheRcBagandits 
subcomponents into its notify set. Once a QueenBee has 
issued the command for each of its workers to do some 
work, it can wait for notification of changes to the RcBag 
to gather results. The following code listing shows the 
methods to add the RcBag to the notify set, and to find 
all WorkerBees and perform the handshake with them: 


method: QueenBee 
addH iveToNotifySet 

" put the RcBag and all of its subcomponents in the notify 
set" 

System addToNotifySet: hive, 
hive doSessionBags: [ 

:addBag :removeBag | 

System addToNotifySet: addBag. 

System addToNotifySet: removeBag. 

] 


method: QueenBee 
getWorkerBees 

''Find possible worker bees, then perform a handshake to 
see if they are available for work. Set the array of worker 
bee's session id's with those that are available." 

| possibleWorkers | 

" find all users logged in as WorkerBee" 
possibleWorkers 
:=System currentSessions 
select: [ :sessld | 

((System descriptionOfSession: sessld) at: 1) 
userid ='WorkerBee' 

]■ 

" initiate the handshake" 
possibleWorkers do: [ :sessld | 

System sendSignal: handshake 
to: sessld 

withMessage: name. 

]■ 

workers :=Array new. 
possibleWorkers size timesRepeat: 

[ | signalArray | 

signalArray :=System signal Fro mGemStoneSession. 
signalArray isEmpty 
ifFalse: [ 

| signalSender signalNumber signalBytes | 
signalSender :=signalArray at: 1. 
signalNumber :=signalArray at: 2. 
signalBytes :=signalArray at: 3. 

" check if WorkerBee was available" 
(signalNumber = handshake and: 

[ signalBytes ='Available' ]) 

ifTrue: [ workers add: signalSender ] 

] 

] 

Themechanismsdescribedinthiscolumn letonesession 
find out about and communicate with other sessions. 
These mechanisms provide the infrastructure to build 
complex applications in a multiuser environment. M 
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